What Makes a Website Accessible?
On this page
No matter what your role is, paying attention to these areas can help you create accessible sites and applications:
- Inclusive & intuitive design
- Headings, landmarks, and semantic structure
- Text alternatives
- Accessible forms
- Interactivity
Video Transcript
What makes a website or app accessible? We've talked about a lot of terminology, kind of level setting and we could keep going. There's lots of definitions but those were the ones that I felt were the most applicable to what we're gonna talk about in this series. To make sure that we're kind of setting the scene for what goes into a website or app that could apply to any type of role, maybe you're not a designer or developer. You wanna share this information with your leadership, things like that. Here are the things that are like if you could nail these, we would be in a lot better shape than we would be in the tech landscape these days. So in inclusive and intuitive design, headings, landmarks and semantic structure, text alternatives, accessible forms, and interactivity.
Inclusive & Intuitive Design
Accessibility should be considered in the design phase, before any code is written.
It’s unfortunately common for many designers to take a subjective tastemaker approach that puts forward an aesthetic at the expense of usability.
Visuals are a big part of this.
Colors should have bold contrast between foreground and background so text is discernible. Layouts should reflow and accommodate for zooming and variable text sizes. Touch targets should be appropriately sized for human fingers.
There are also considerations like using obvious designs for interactive controls and allowing for users to opt-in to motion and animation.
We’ll revisit these topics with more depth in the Design & People Skills for Accessibility workshop. But it is good to keep these considerations in mind.
Video Transcript
Inclusive and intuitive design. And I have a graphic from a colorblindness test. It's really pretty. It has all these multicolors and, kind of, a heart in the middle. Depending on how you perceive color and your brain processes color information, you may or may not be able to see that heart in the middle. So everyone's different and how everyone sees color is different, and that can impact how you interact with things in the world and in digital spaces. So a big part of inclusive and intuitive design... well it starts with the need for accessibility before coding. I mean, we've talked about that a little bit. Trying to get accessibility thought of before we're trying to bold ARIA attributes onto things. And as I mentioned, I'm often going, "I, kind of, think this is more of a design problem than an engineering problem," 'cause we can only fix it for coding or for users so much with code. So some parts of this that become increasingly important, bold visual contrast, hence the colorblindness graphic. So making sure that your foreground and background colors have enough of a range between the two colors that you can tell them apart. And that you can tell when something is being interacted with, you know, the contrast of interactions and things like them. Unfortunately, I think over the years the, sort of, subjective approach of many designers has been subtlety and tiny text and things. And it's such a personal preference that ends up getting like, you know, they're taste makers and decision makers and, you know, trying to have the designers aesthetic be the setting, the taste for everyone, doesn't always work. You know, often usability can suffer because stuff is just so hard to see, so hard to use. And so I think, you know, if it were tested with people more it might counter some of those biases and assumptions that what is beautiful to someone might be super unusable to someone else. Adjustable text and layouts. So that tiny text, if we could at least zoom in, that would help make sure the layout doesn't break when you zoom in and the browser, or if you're using a magnifier or something, making things responsive is part of that. So as you zoom in the screen width changes, and if it can reflow into a single column, the design will have to account for that, but that is absolutely an accessibility piece. And that is one of the success criteria for accessibility, is what we call reflow. So making things adjustable, so not like baking all your text in with graphics and stuff, or locking down orientation so that you can't flip your phone or whatever. There's some exceptions, like if your interface... say it's like a banking app and you're taking a picture of a check to deposit it in your bank account, like, okay, that needs to be landscape format. But otherwise, just locking it down to make it really restrictive, just out of a personal taste or something, not a good enough reason. So making things flexible and, kind of, letting go of that expectation of pixel perfection. And we talked about that a little bit with accessibility APIs and even, you know, with SVG and things like that, flexibility and just acceptance that things are gonna move and, you know, users are gonna visit from different browsers and things. That adjustability and adaptability can make stuff more usable in a wide range of places, and that's, frankly, good design. Touch targets large enough for human fingers, and movement so these tiny little buttons that, like, whose fingers can even touch those? I don't know, haven't been tested with people or trying to move a mouse cursor on your desktop when you have a tremor or something. And it's really hard to get to that menu because the target is so tiny. I, you know, I've been spending a lot of time in Google slides and trying to change the fonts. And like, how do... I cannot get to the font, and I work on a computer every day. So making things easy to move to, but then also, you know, in touch devices, providing targets that are large enough for actual humans to use. Part of that is making obvious, interactive controls. So not assuming that people know what icons mean, making things like really clearly interactive, sometimes stuff just gets buried. Maybe it's like a design anti pattern, you know, like the unsubscribe link that doesn't look like one. But making things more obvious is important. It really makes stuff more usable to a wide audience. And so, of course, you know, some products or services might have a very specific audience. And, you know, what we call pro level tools or something, like, do user testing with that audience to know what works and not, don't make assumptions. I still think that even on pro level software, having larger touch targets and making things obviously interactive versus static content, even with an advanced level audience, that's still gonna be helpful. 'Cause people have to onboard somehow, you know? Okay so, opt in for motion and animation. And we'll talk about this quite a bit more on Thursday, but not assuming that everybody wants that whimsy and delight of things moving automatically on a screen that can definitely make people sick or worse. Never come back to your site again. It's like, "Oh, I can't use that site 'cause it gives me a migraine every time. Making that opt in, you know, like allowing people, giving them some warning, and opt out is one way to do it. Opt in is preferred because then you're not putting that expectation on someone who is sensitive to motion that, like, ah, they can opt out, well, you might have harmed them in the process. So that's what inclusion would be about, is, kind of, designing for people knowing that they they might not be able to experience something safely on the web if it's moving, might set them off in some distraction spiral where they can't get anything else done for the rest of the day. That would be problem. And yeah, more to come in our design and people skills workshop. We talk a lot about this stuff and talking specifically about, kind of, like where design and development, how we come together to set things up so that when we are implementing with code, we've already been thinking about accessibility as well as kind of the process around all of this. Like feedback loops and thinking about accessibility as we do our work, so I'm excited for that.
What are HTML Headings?
Using proper HTML headings creates a content hierarchy that screen readers can navigate.
Headings are numbered from h1 to h6, and can be thought of similarly to what an outline in a word processor might look like.
It’s important that there’s only one h1 per page and that heading levels increase in order instead of skipping around.
Another common mishandling of HTML headings is choosing them based on text size. Styling text is a job for CSS, not HTML!
The underlying structure & content of our sites should be intentional, separate from the presentation. Headings help with that.
Video Transcript
HTML headings are a big part of web development and I have a graphic on the screen from the web developer toolbar extension. It works really great in some cases. It's nice to have a variety of tools, which we'll talk about a lot in our manual testing and tools workshop, but the graphic is showing a series of headings that create a semantic structure. And that's really what headings are for. They create a content hierarchy that screen reader users can navigate, so navigating by, from heading to heading, and we have h1 through h6, there is not an h7 element. I think at one time maybe there was going to be but we have h1 through h6 and those are the heading levels that we have to create an outline. And I liken this to Microsoft Word, it's kinda like when you're creating an outline with Roman numerals and bullets and things and you indent and it creates this structure, right? So, we can create that using headings and other semantic elements we'll touch on but headings are a huge part of it. They're a really well known way for screen reader navigation. Super critical. So, some guidance on using headings. There should only be one h1 per page and we'll talk a little bit about some of the gotchas of that in later workshops, but kind of the most important thing to know is that there should only be one h1 per page. Headings shouldn't skip levels. So, in the graphic I have, they're all green and they're all going nicely from h1, h2, to h3. We're not skipping around, there's not, like, a missing h1 and in the web developer toolbar, it'll show in yellow and say missing or something and so it's helpful to see when you've missed heading levels, because we want that structure to kind of create this hierarchy and if we skipped around, the hierarchy wouldn't follow any real flow. Like this heading wouldn't be nested under the one before it. And so, we think about it like, you know, I have an h1 of testing accessibility, an h2 of workshop resources list, and then all the h3's go under workshop resources list. So they're kind of nested and create that structure so all of the content, it creates a non-visual structure that can be really helpful for navigating when you can't see the screen. And levels apply to the content, not the style. So this is often what trips people up, it's like, "Ugh, but my design system, you know and these fonts are tiny and they, but they come like right at the beginning, you know, it's like, I have no big h1. And I have these little like label looking things." And like, maybe you're going off a design and it's not clear, you know, it's not following a really obvious content hierarchy like this, but that's the content that's on the page. So we really wanna apply, like, think about the content structure, kind of take the content or the style part away. Just think about the HTML part. What is the structure of this from a content perspective? And sometimes that might mean adding an extra heading in there. That's what we call visually hidden, so that you can kind of introduce a section. So we're really thinking about the overall content structure and we can use CSS to style them. So the whole like, but these fonts are so tiny and it just, it doesn't look like an h2. It's like, well, CSS can style it, however you like. And so having utility classes and things that you can apply, means that you can choose the correct level of the, the HTML markup and then style it however you want. It's awesome. So headings are, are critical and yeah, CSS is really powerful. That's why we can separate the structure from the presentation and create something that like that HTML structure is very important. The style, you know, it does need to be well designed as we were just talking about, but thinking of the content kind of independently from the style, means that we can create something that's works really well in assistive technology.
What are HTML Landmarks?
HTML5 landmark elements give us a method to wrap our content into semantic sections.
All of the content on our page should be wrapped inside of one of the landmark elements supported by all newer browsers:
<header>, <nav>, <main>, <footer>,<section>, <article>, <aside>
In the Semantic Markup with HTML & ARIA workshop we’ll go more in-depth into the accessibility features these elements give us “for free”.
For now, the big takeaway is that using these elements allows someone using assistive technology to navigate & understand our content even if they can’t see the screen.
Video Transcript
So similar to headings are HTML5 landmarks. Now I have another screenshot of another tool called accessibility insights and there is a landmarks visualizer in there that's pretty awesome. So landmarks wrap up content to mark up major semantics sections. They're almost like sign posts, it's like we have headings within landmarks but all of the content on our pages really should be in some kind of a landmark. So in the graphic from the testing accessibility resources list, there's a banner landmark kind of around the header. And then all the main content is in a main landmark or LM as they abbreviate in accessibility insights. And so these are kind of a newer thing, it's part of HTML5, so we haven't always had them but they're supported in all newer browsers. And there's really no reason not to add landmarks as long as we use them kind of following a few tips or a few rules. So some of the elements that this includes are header, nav, main, section, article, aside and footer and these elements come with accessibility information built in. So as we talk about semantics, we'll learn all about what you get for free with these elements. So assistive technologies can navigate by these landmarks as well. So you can navigate by different collections. So headings, you can navigate by landmarks. And so having stuff marked up in a banner, header banner, being a top, what we call, a top level landmark, that makes it really easy to identify what content is kind of like marked up in that top area of a webpage even if you can't see the screen. And so if we use these elements, it can just add some more foundational structure to our webpages that can be super helpful. So it's kind of explaining under the hood what's happening without having to see the screen.
What are Other Semantic Elements?
We can add more semantic structure beyond just headings and landmarks, even though those are key parts of it.
Some common elements include <p> for paragraphs and <ul> and <ol> for lists.
It is possible (and common) for developers to build their own custom buttons and tables in their web apps, but using the built-in <button> and <table> elements and then applying styles is a better way to go.
Using semantic elements can provide better support for assistive technologies by default. It also ends up being less work than if we had to add accessibility features manually.
Work smarter, not harder!
Video Transcript
So what are some other semantic elements? So, we can add a lot more semantic structure beyond headings and landmarks, even though those are a big part of it. We can get so much information for free. Like, it's so worth it to use these elements. I cannot stress that enough. We can get all kinds of accessibility information for free. So I kind of alluded to, you know, with landmarks, we get some accessibility information for free. Like, what type of element is it? Is it a banner landmark? Is it a main? A lot of these elements under the hood. And we, we've mentioned Aria, you know, I don't wanna spoil too much, but, there's a lot of stuff we get kind of under the hood for accessibility by using these elements. So some elements that this includes are unordered lists. So UL, ordered lists are OL, P for paragraphs, buttons, tables, figures, HR, or horizontal rule. These elements when you use them, not only do they, like, have default styles, like, the user agent style sheet, as we talked about earlier. So, like, buttons have certain styles. You know, tables, you can structure tabular data. You know, if you're creating annual report, or something that actually should be in a table, not only did those elements kind of create a structure with that default style sheet, but there's accessibility information that comes with it. So it will be communicated as a table, or a button in a screen reader or other assistive technology. And it is possible to re, recreate some of this stuff with Aria as we'll talk a lot about. But it's so much easier if you can use it for free. It's a lot less work. And, you know, we like to be lazy where we can, right? So work smart, not hard. And being smart about accessibility is using as much for free as you can, because the support for it is much better. You know, you can count on an unordered list, often. There is a gotcha. But things like paragraphs, and buttons, and lists, you know, in a lot of places, you get behavior for free. You know, a grouping of list items. Some interactivity with buttons, and it's a lot of code that you didn't have to bolt on. And that takes less time, both to create, and to test and maintain. And assistive technologies like headings and landmarks, you can navigate by a lot of these collections as well. So navigating by buttons or links, you can kind of jump from element to element by element type. Images is another one. And so, these element types, you know, we talked about HTML, how we go from tags to Dom objects. That's a big part of what these semantic elements are all about. As it reads, you know, through the rendering process in the browser, it will, you know, look at those angle brackets and say, "Okay, angle bracket, open, UL, close angle bracket." That UL will become an unordered list object, or a list object with style attached to it. And so those element names are really important. Like they, they actually become objects. And so, yeah, if you think about things like forms, which we'll talk about in a second, that's a similar process and you might have entire browser APIs that you can access based on what type of element it is. So assistive technology navigating by these types kind of hinges on that same thing, that these are known objects. They have properties to them. So that's super cool. You know, if it was a div, you wouldn't get that. And we'll cover this in depth in semantic markup with HTML and Aria. So talking about, you know, how to create these, how to style them, how to test for them, kind of next level stuff to set us up for interactions with JavaScript. Yeah. So if we could use more semantic elements, a lot of this stuff, we would be in really good shape. So, yeah. Take that back to your work.
What are Text Alternatives?
Whether it’s a meme or an infographic, graphics and non-text content needs to be described so readers can be included.
Every purposeful image you use on a website needs to include meaningful alt text.
This is done using the alt attribute.
Note that this is an “alt attribute” not an “alt tag”!
Writing image descriptions can be highly subjective. Does the image serve a purpose and contribute to the page narrative, or is it strictly decorative and presentational?
My favorite resource for determining what to use as an alt description is the W3C’s alt decision tree.
Working with video and audio requires additional considerations.
Streaming video and audio content should include captions as an alternative to the spoken word. Audio descriptions are a text alternative included in several Netflix shows that describe what’s on screen beyond simple dialogue, with more providers beginning to add them for better entertainment experiences. Live sign language interpreters also fall under text alternatives.
The WCAG guidelines include more information about requirements for text alternatives.
Video Transcript
Let's talk about text alternatives. And I mentioned tags once already. We've been talking about HTML tags that we write in our text editor. When we talk about images, text alternatives refer to graphic and non-text content that needs to be described so it can be used in formats that people need, such as large print, braille, speech symbols, or simpler language. So when you have an image, we need to put alt text on it. And this is where the alt tags comes in. It is alt text, not an alt tag. So the image part in this code example is the tag, so IMG. The alt attribute or alt text, so the attribute is the word alt, and then you have equal sign quotes. And within the quotes, that alt text is what we call a text alternative. And so my snarky comment for today is that they're not alt tags. You can out yourself as not knowing the correct terminology. So alt text or alt attribute along with the source of an image that you have loaded, alt text should describe what is in that image, with some exceptions. But this is, like, the main thing that we talk about with text alternatives, is that we're really describing what's in an image so that people can be included. If they can't see the screen, what are we lookin' at, what are we talkin' about? Is this a cheesy stock image? Is it the butt of a joke? I mean, you might be completely left outta the joke if you don't know what's in the image. Or a meme or something like that. So this includes photographs. Infographics are a big one. They often have a ton of text baked into them. Icons or icon buttons, and other non-decorative images. So I have a link here, my favorite resource, to the W3C, the Web Accessibility Initiative has what's called an alt decision tree that they talk about in here. So, this link is about decorative images. So if something is truly decorative, say it's, I don't know, like a spacer gif. You remember those. Like an image that literally has nothing in it. Or maybe it's just, I don't know, like some graphic thing that it's just kind of extra and doesn't really add any content, you can mark something with an empty alt attribute if it is decorative. But that's super subjective. We'll talk about that more later. But alt text, often we want to describe things so people aren't left out. But we don't wanna assume that people don't need content, so think long and hard about whether it's decorative or not. And you'll have to make that decision, which can be difficult sometimes. Pick one and go with it. So for text alternatives, there's also time-based media. So for video and audio, we need captions. Pretty obvious. If you're putting out video content, like if we were to share this video, we do have live captions in this workshop. When we're putting time-based media out, that people can kind of navigate through with a scrubber, like on YouTube or other video players, and we need captions so that it is inclusive and it has an alternative to this spoken word that people might not be able to hear. There's also audio descriptions, which are really great for blind and low vision folks. So that if you can't really see everything that's happening on the screen, you get more of a description than just the dialogue. 'Cause maybe you don't know who's saying what, or they have, like, really shaky body posture when they're saying. There's more information, like nonverbal information, that might be communicated that you would miss out on without audio description. So there's some really great audio descriptions on Netflix shows, and more and more popping up. There's also sign language. So if you're watching a government broadcast or something, and they have a sign language interpreter kind of in a picture in picture thing, that would fall under text alternatives. And these are requirements in the web content accessibility guidelines. So you can read through text alternatives to read about what the responsibilities are there.
Accessible Web Forms
Forms are a huge part of the web. They’re also one of the most common things that are done wrong.
There are a number of form controls for collecting user input.
Choosing from the browser default elements when building your forms provides a lot of accessibility wins for free. But they can be tricky to style.
This is often why teams will choose to roll their own custom form controls or search around the web for examples.
Often this isn’t worth the time and bugs encountered.
Form markup provides semantic structure. The <form> element wraps groups of form controls that are marked up to respond to keyboard presses. Even though JavaScript can do a lot with individual inputs, creating a whole semantic form structure has accessibility benefits.
One of the most important accessibility features that is forgotten is adding labels to inputs and textareas. There are multiple benefits to adding labels. When a label and input are bound properly together, the increased interactive click area will automatically focus you into that input.
Labels programmatically inform screen reader users what an individual control is for: “do they want my first name or my full name?”
Label text should be visible to all users and not hidden with a CSS technique or shown only as an input placeholder. This helps to reduce the cognitive overhead that can come from typing in a placeholder-only field: “what am I typing, again?”
Validation is the last important thing to remember for accessible forms. When a form has been filled out incorrectly, feedback must be provided accessibly to users. This means doing the work to expose error text to assistive technologies.
In the Coding Accessible Interactions workshop we’ll look at these topics in detail.
Video Transcript
Accessible forms. This is a huge one and often something that gets, people get wrong. So forms are things that collect user input and submit to a server. They might provide oAccessible forms, this is a huge one and often something that gets, people get wrong. So forms are things that collect user input and submit to a server. And they might provide other functionality. Like, maybe the form, you know, it's not actually hitting a server to do anything but maybe you're collecting user input and then just doing things dynamically in the browser with JavaScript. All kind of use cases for forms and form elements, some often what we call controls, that's these interactive pieces of web forms. The default elements that come along with forms give you so much behavior for free. And I sort of mentioned this a little bit talking about other semantic elements, but forms, you get actual APIs in the document object model. Like, you can access forms with the API document.form or forms, one or the other. I usually have to look it up. But like, there's special functionality that you get with these elements, and trying to recreate, for example, everything that a select can do, it's a lot. And you often miss out on some things that you would've gotten for free with a default select element. But they're hard to style or impossible to style. And so that's often when teams will try to roll their own form control for some reason is because they wanna style it and make it look branded or work a certain way. But just remember, you might be sacrificing a lot of free behavior that then you don't have to build and maintain. And often, like, literally when you get to the other end of having built your own custom thing, you might realize that it wasn't worth it. All the bugs, trying to get accessibility right, yeah, you really have to think was it worth it, and try and make that call up front and save yourself some time. So form markup provides semantic structure. We have the form element that really should wrap everything that can impact how you interact with the components within a form. Fieldset and legend, so those can kind of wrap groups of form controls. And when you have the form element wrapping everything, for example, when you are using an input or a textarea, especially with Inputs, but if it's wrapped in a form tag and you hit the Enter key, depending on how exactly it's marked up, but often that form element is what can make you submit on the Enter key. And so there's parts of that that can change behavior in assistive technology and using the keyboard. So even though you can do a lot with JavaScript with individual inputs or other pieces of forms, trying to create a whole form around something has accessibility benefits. So that's important to keep in mind And with inputs and textareas, they really need label elements. And this one is forgotten so much all the time. Yeah, and it's a shame too, because the label will actually add an increased click area. Like, if you click on the label and it's bound properly with an input or a textarea, it will put your focus into that input. So it just makes it, increases the interactive area for this interactive element. So, labels, we need them. Especially because if you don't label an input or a textarea, how is a blind person gonna know what that input is for? Like, put my name here? It might have a placeholder on it or something and that, technically, we'll talk a lot about this, but you know, it's helpful, but we still want labels. And I'll tell you why a little later. So this includes text inputs, radio buttons, checkboxes, textareas, selects. They all need to be labeled. So like, what is this particular radio button for? You know, visually, it might not be enough. We need to programmatically communicate to assistive technology what is this particular checkbox for. Is this going to subscribe me to the newsletter? You know, often there'll be checkboxes that you can't reach with the keyboard so like, a keyboard user can't opt out of spam email or something. Yikes, so yeah, we need. By using these default elements, we get a lot of keyboard behavior for free. I mean, if we label them, then assistive technology users can follow along with trying to fill out this form effectively and not have to ask for help. It's like we talked about banking and stuff. Like, web forms is a huge part of that and that's often where accessibility can fall down is that we haven't built accessible forms. If someone with a disability, like, it's not a nice to have. It's a requirement for someone to be able to check out or to be able to complete a process? This is kind of the nuts and bolts of like, where that comes together a lotta times is creating accessible markup, like, functionally for the keyboard, but for screen readers as well. So yeah, it's not just like I'm just telling you this because it's nice to talk about. No, it's like, the actual reality of not having it means that someone can't do independent tasks. So yeah, this is kinda like on the ground level, you know, what that means is creating accessible forms. We want to ensure that access is not lost as a result of custom styling. And sometimes, this can be tough because you're handed a design and they really, really want a custom checkbox or whatever the pattern is. And a lot of those things, you know, you can Google it and find a demo, like, find out how to make a customer checkbox or whatever. And there are a lot of patterns where you can make it work. Some not so much, and so historically, it's been really challenging. The good news is that browsers are, they're working on making these things easier to style. Fingers crossed, especially select, 'cause that one has been the hardest. But you really wanna test stuff. Like, if you're grabbing a pattern, you know, okay, I'm validating that this blog post I found that tells me how to style a custom whatever, test it, make sure it works. So that's a big thing that we'll talk about is making sure that we're not losing access and just assuming that they said it was accessible and it's accessible, right? Well, you have to go test it yourself because the way you've implemented it, like, maybe they had some quirk to their implementation that made it work or maybe it used to work, or maybe it only works in Chrome and it doesn't work with MVDA or something. Like, we wanna go and validate and make sure. 'Cause often, you know, we're trying to satisfy our design requirements and accessibility requirements. That can be a little tricky sometimes. And one more bit on accessible web forms is about validation. So when the user submits a form, if they didn't fill it out correctly or, you know, there's some reason why they need to go back and check a field, there are patterns that we can follow that will provide feedback more accessibly to users. And I have a link in here from Web Aim, one of my favorite groups, about form validation. Just some thing to keep in mind. So making sure that it's clear visually as well as in a screen reader which fields need to be revisited. So there's various ways to do that. Big part of forms. You know, I've seen stuff get done visually, like, oh, there's an error message, but maybe that's not, they didn't take it all the way to pipe that through to screen reader. Yeah, we'll talk about that in a later workshop, as well.ther functionality, like maybe the form, you know, it's not actually hitting a server to do anything, but maybe you're collecting user input and then just doing things dynamically in the browser with JavaScript.
All kinds of use cases for forms and form elements. Often what we call form controls. That's these interactive pieces of web forms. The default elements that come along with forms give you so much behavior for free. And I sort of mentioned this a little bit, talking about other semantic elements, but forms you get actual APIs in the Document Object Model. You can access forms with the API document.form or forms.
One of the other, I usually have to look it up. But like there's special functionality that you get with these elements and trying to recreate, for example, everything that a select can do, it's a lot. And you often miss out on some things that you would have gotten for free with a default select element.
But they're hard to style or impossible to style. And so that's often when teams will try to roll their own form control for some reason, it's because they want to style it and make it look branded or work a certain way. But just remember, you might be sacrificing a lot of free behavior that then you don't have to build and maintain.
And often, like when really, like when you get to the other end of having built your own custom thing, you might realize that it wasn't worth it. All the bugs trying to get accessibility right? Yeah. You really have to think, was it worth it to try and make that call upfront, save yourself some time. So form markup provides semantic structure.
We have the form element that really should wrap everything that can impact what, how you interact with the components within a form. Fieldset and legend. So those can kind of wrap groups of form controls. And when you have the form element wrapping everything, for example, when you are using a, an input or a text area, especially with inputs. But if it's wrapped in a form tag and you hit the enter key, depending on how exactly it's marked up, but often that form element is what can make you submit on the Enter key.
And so there's, there's parts of that that can change behavior and Assistive Technology and using the keyboard. So even though you can do a lot with JavaScript with individual inputs or, you know, other pieces of forms, trying to create a whole form around something has accessibility benefits. So that's important to keep in mind.
And with inputs and text areas, they really need label elements. And this one is forgotten so much, all the time. Yeah. And it's a shame too, because the label will actually add an increased click area. Like if you click on the label and it's bound properly with an input or a text area, it will put your focus into that input.
So it just makes it increases the interactive area for this interactive element. So labels, we need them, especially because if you don't label an input or a text area, how is the blind person going to know what that input is for? Like put my name here. It might have a placeholder on it or something.
And that technically we'll talk a lot about this, but you know, it's, it's helpful, but it's still, we still want labels and I'll tell you why a little later. So this includes text inputs, radio buttons, checkboxes, text areas, selects–they all need to be labeled. So like, what is this particular radio button for?
You know, visually might might not be enough. We need to programmatically communicate to Assistive Technology. What is this particular checkbox for? Is this going to subscribe me to the newsletter? You know, often there'll be check boxes that you can't reach with the keyboard. So like a keyboard user can’t opt out of spam email or something.
Yikes. So yeah, we need, by using these default elements, we get a lot of keyboard behavior for free. And if we label them then Assistive Technology users can follow along with trying to fill out this form effectively and not have to ask for help. Like we talked about banking and stuff, like web forms is a huge part of that.
And that's often where accessibility can fall down is that we haven't built accessible forms. If someone with a disability, like it's not a nice to have. It's a requirement for someone to be able to check out or to be able to complete a process. This is kind of the nuts and bolts of like where that comes together.
A lot of times is creating accessible markup, like functionally for the keyboard. But for screen readers as well. So yeah, it's not just like. I'm just telling you this, you know, cause it's nice to talk about. No, it's like the actual reality of not having it means that someone can't do independent tasks.
So yeah, this is kind of like on the ground level, you know what that means is creating accessible forms. We want to ensure that access is not lost as a result of custom styling. And sometimes this can be tough because you're handed a design and they really, really want a custom checkbox or whatever the pattern is.
And a lot of those things, you know, you, you can Google it and find a demo, like figure out how to make a custom checkbox or whatever. And there are a lot of patterns where you can make it work. Some not so much. And so historically it's been really challenging. The good news is that browsers are, they're working on making these things easier to style.
Fingers crossed, especially select, ‘cause that one has been the hardest. But you really want to test stuff. Like if you're grabbing a pattern, you know, okay. I'm validating that this, this blog post I found that tells me how to style a custom whatever. You know, test it, make sure it works. So that's a big thing that we'll talk about is making sure that we're not losing access and just assuming that they said it was accessible.
“It's accessible, right?” Well, you have to go test it yourself. ‘Cause the way you've implemented it, like maybe they had some quirk to their implementation that made it work. Or, maybe used to work. Or maybe it only works in, you know, in Chrome and it doesn't work with NVDA or something. Like we want to go and validate and make sure. ‘Cause often, you know, we're trying to satisfy our design requirements and accessibility requirements.
It can be a little tricky sometimes.
And one more bit on accessible web forms is about validation. So when the user submits a form, if they didn't fill it out correctly. Or, you know, there's some reason why they need to go back and check a field. There are patterns that we can follow that will provide feedback more accessibly to users.
And I have a link in here from WebAIM, one of my favorite groups about form validation just some things to keep in mind. So making sure that it's clear visually as well as in a screen reader, which fields need to be revisited. So there's various ways to do that. Big part of forms. You know, I've seen stuff get done visually like, oh, there's an error message, but maybe that's not, they didn't take it all the way to pipe that through to a screen reader.
Yeah, we'll talk about that in a later workshop as well.
Interactivity Goes Beyond the Mouse
Anything that a mouse user can do, a keyboard and screen reader user must also be able to do.
This doesn’t necessarily mean that the interaction needs to be exactly the same, but there should be a way for someone using assistive technology to complete their task.
Think inclusive design.
One of the most common mistakes I see in my consulting work is developers using <a> tags without including an href attribute which is required to navigate. This tells me a lot about their workflow– mostly that they don’t test with a keyboard. If you need something for users to interact with that doesn’t include a URL, a button with some JavaScript is the better choice.
Using the right HTML elements can provide keyboard interactivity for free! Additional functionality can be added with JavaScript and DOM events.
One of my favorite examples we explore in the workshop series is an accessible date picker component that works with the keyboard and plays nicely with a screen reader. It’s a combination of the topics we’ve talked about, and is applicable to the components you’ll work with on the job.
Video Transcript
And interactivity, one of my favorite parts. Interactivity goes way beyond the mouse or the track pad. So the keyboard is a huge part of it, but we talked about assistive technologies. There were other parts of that too, so text to speech and speech recognition. There's other technologies that layer on top of an accessible web application that goes beyond navigating by mouse. So any task that a mouse user can do, keyboard and screen reader users should also be able to do, and maybe they don't do it exactly the same way as a mouse user. Maybe there's a button that is there for keyboard users or screen reader users. Also, maybe you can click on a whole card pattern, but that's wired up with JavaScript. And the keyboard accessible thing is the linked heading inside the card. You can do the same task, but maybe the actual thing that you act upon is slightly different. That's okay 'cause you can still complete the same task. And that's where talking about inclusive design versus universal design, it's inclusive if a keyboard user can still do the thing even it's not the universal exact same affordance as we call it. Maybe they're doing it slightly differently than a mouse user, but we're not preventing them from clicking that link or toggling a button or accessing a different menu, or something, making sure that keyboard and screening users aren't prevented from completing tasks. And as we've talked about, some HTML elements provide keyboard interactivity for free. So we wanna make use of that wherever possible 'cause it's less to manage, it's less code to write, using form controls, using buttons, the trusty button element. It's awesome, you should use it cause you get a lot of stuff for free. And so there's the button, the anchor element, which needs an href attribute to actually navigate you somewhere. I can't even tell you how many times I see anchor elements that don't have hrefs and it just tells me that the team never tested it with a keyboard because without that href, 'cause it's meant to have a URL that navigates the user somewhere, if it doesn't have that href, you can't reach it with the keyboard. And so yeah, it's interesting when I'm testing a user interface, I can always tell a bit about their workflow if I find things like anchors without hrefs. I'm like, oh, they didn't test this with the keyboard at all. And yeah, if you're putting an anchor and feeling like it, well, it doesn't have a URL, and so it doesn't have an href, then it should probably be a button if it doesn't navigate the user somewhere. 'Cause then you don't need that href, you can get the functionality on the button and add JavaScript to it. There's also the details and summary elements, that's kind of a native accordion sort of thing. Those are keyboard accessible by default. So the more that we can use these default elements, the more that we can free ourselves from having to have accessibility issues, but also not have to create custom everything. And a note on interactivity, keyboard operable elements can be reached with the tab key. So if I'm going, tab tab, tab, it will take me to buttons and anchors with hrefs, inputs, those kinds of things. It won't tab me onto things like headings. That is expected because screen readers have other ways of navigating. And there might be a setting you have to change in Safari or on your operating system if you're not able to reach every interactive element with tab, but just know that interactivity, the tab key is that's how keyboard users navigate. Screen readers have other ways of navigating, but things that are meant to be interactive, kind of this center of it all is the interactivity using the tab key keyboard operability. And then JavaScript and DOM events as we've talked about, that's what adds functionality onto that. So like if I have a button in HTML I can make it focusable with HTML by itself, but it's not gonna do anything unless it's in a form, like a super traditional form, maybe that button could submit to a server. But increasingly we're using buttons for interactivity in these rich web applications, and JavaScript and DOM events are what add that functionality on there, so I love that part. Working with events I think is so cool. You can interact and add really cool stuff and do things. And so it's that intersection of HTML and JavaScript. So both the manual testing and coding accessible interactions and mechanics workshops will go into a lot of this kind of stuff like testing for it, especially the coding one. We'll be talking about ins and outs of what works with the keyboard, what works with the screen reader, all the different pieces that go into interactivity. So I'm psyched about that. It'll be fun.